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Deprecate Triple-DES (3DES) and RC4 in Kerberos 
Abstract 


The triple-DES (3DES) and RC4 encryption types are steadily weakening 
in cryptographic strength, and the deprecation process should begin 
for their use in Kerberos. Accordingly, RFC 4757 has been moved to 
Historic status, as none of the encryption types it specifies should 
be used, and RFC 3961 has been updated to note the deprecation of the 
triple-DES encryption types. RFC 4120 is likewise updated to remove 
the recommendation to implement triple-DES encryption and checksum 
types. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 
BCPs is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8429. 
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Copyright Notice 


Copyright (c) 2018 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Introduction 


The triple-DES (3DES) and RC4 encryption types (enctypes) ar 

steadily weakening in cryptographic strength, and the deprecation 
process should begin for their use in Kerberos. Accordingly, RFC 
4757 has been moved to Historic status, as none of the encryption 
types it specifies should be used, and RFC 3961 has been updated to 
note the deprecation of the triple-DES encryption types. RFC 4120 is 
likewise updated to remove the recommendation to implement triple-DES 
encryption and checksum types. 


Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Affected Specifications 


The RC4 Kerberos encryption types (including rc4-hmac) are specified 
in [RFC4757], which has been moved to Historic status. 


The des3-cbc-shal-kd encryption type is specified in [RFC3961]. 
Additional triple-DES encryption type codepoints are in use and in 
the IANA registry with no formal specification, in particular 
des3-cbc-md5 and des3-cbc-shal. These unspecified encryption types 
are also deprecated by this document. 


The Kerberos specification ([RFC4120]) includes recommendations for 
which encryption and checksum types to implement; the deprecated 
encryption and checksum types are now disrecommended to implement. 


Though the RC4 and triple-DES encryption types are still in use in 
some deployments, the above status changes are made to discourage 
their use. 
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4. Affected Encryption Types 


The following encryption types are deprecated. The numbers are th 
official identifiers; the names are only for convenience. 


4+---------------- 4+-------------------------- + 
ncetype number enctype convenience name 
4+---------------- 4+-------------------------- + 
5 des3-cbc-md5 
7 des3-cbc-shal 

16 des3-cbc-shal-kd 
23 rc4-hmac 
4+---------------- 4+-------------------------- + 


5. RC4 Weakness 


RC4’s weakness as a TLS cipher due to statistical biases in the 
keystream has been well publicized [RFC7465], and these statistical 
biases cause concern for any consumer of the RC4 cipher. However, 
the RC4 Kerberos enctypes have additional flaws. These flaws reduce 
the security of applications that use th nctypes; the weakening 
occurs for various reasons, including the weakness of the password 
hashing algorithm, the reuse of key material across protocols, and 
the lack of a salt when hashing the password. 


5.1. Statistical Biases 


The RC4 stream cipher is known to have statistical biases in its 
output, which have led to practical attacks against protocols such as 
TLS that use RC4 [RFC7465]. At least some of these attacks rely on 
repeated encryptions of thousands of copies of the same plaintext; 
although it is easy for malicious javascript in a website to cause 
such traffic, it is unclear whether there is an easy way to induce a 
kerberized application to generate such repeated encryptions. The 
statistical biases are most pronounced for earlier bits in the output 
stream, which is somewhat mitigated by the use of a confounder in 
Kerberos messages: the first 64 bits of plaintext are a random 
confounder, and are thus of no use to an attacker who can retrieve 
them. 


Nonetheless, the statistical biases in the RC4 keystream extend well 
past 64 bits and provide potential attack surface to an attacker. 
Continuing to use a known weak algorithm is inviting further 
development of attacks. 
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5.2. Password Hash 


Kerberos long-term keys can be either random (as might be used in a 
service’s keytab) or derived from a password (e.g., for individual 
users to authenticate to a system). The specification for a Kerberos 
encryption type must include a "String2key" algorithm for generating 
a raw crypto key from a string (i.e., password). Modern encryption 
types, such as those using the AES and Camellia block ciphers, use a 
string2key function based on the Password-Based Key Derivation 
Function 2 (PBKDF2) algorithm. This algorithm involves many 
iterations of a cryptographic hash function, designed to increase the 
computational effort required to perform a brute-force password- 
guessing attack. There is an additional option to specify an 
increased iteration count for a given principal, providing some 
modicum of adaptability for increases in computing power. 


It is also best practice, when deriving cryptographic secrets from 
user passwords, to include as input to the hash function a value that 
is unique to both the user and the realm of authentication; this 
user-specific input is known as a "salt". The default salt for 
Kerberos principals includes both the name of the principal and the 
name of the realm, in accordance with these best practices. However, 
the RC4 encryption types ignore the salt input to the string2key 
function; the function itself is a single iteration of the MD4 hash 
function applied to the UTF-16 encoded password, with no salt at all. 
The MD4 hash function is very old and considered to be weak and 
unsuitable for new cryptographic applications at this time [RFC6150]. 


The omission of a salt input to the hash is contrary to cryptographic 
best practices and allows an attacker to construct a "rainbow table" 
of password hashes; such tables are applicable to all principals in 
all Kerberos realms. Given the prevalence of poor-quality user- 
selected passwords, it is likely that a rainbow table derived from a 
database of common passwords would be able to compromise a sizable 
number of Kerberos principals in any realm using RC4 encryption types 
for password-derived keys. 


5.3. Cross-Protocol Key Reuse 


The selection of unsalted MD4 as the Kerberos string2key function was 
deliberate, since it allowed systems to be converted in-place from 
the old NT LAN Manager (NTLM) logon protocol [MS-NLMP] to use 
Kerberos. 


Unfortunately, there still exist systems using NTLM for 
authentication to applications, which can result in application 
servers possessing the NT password hash of user passwords. Because 
the RC4 string2key function was chosen to be compatible with the NTLM 
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scheme, these application servers also possess the long-term Kerberos 
key for those users, even though the password is unknown. The cross- 
protocol use of the long-term key/password hash was convenient for 
migrating to Kerberos, but it now provides a vulnerability in 
Kerberos as NTLM continues to be used. 


5.4. Interoperability Concerns 


The RC4 Kerberos encryption type remains in use in many environments 
because of interoperability requirements. In those sites, RC4 is the 
strongest enctype that allows two parties to use Kerberos to 
communicate. In particular, the Kerberos implementations included 
with Windows XP and Windows Server 2003 support only single-DES and 
RC4. Since single-DES is deprecated [RFC6649], machines running 
those operating systems must use RC4. 


Similarly, there are cross-realm deployments in which the cross-realm 
key was initially established when one peer only supported RC4, or 
machines only supporting RC4 need to obtain a cross-realm Ticket- 
Granting Ticket. It can be difficult to inventory all clients ina 
Kerberos realm and know what implementations will be used by those 
client principals; this leads to concerns that disabling RC4 will 
cause breakage on machines that are unknown to the realm 
administrators. 


Fortunately, modern (i.e., supported) Kerberos implementations 
support a secure alternative to RC4 in the form of AES. Windows has 
supported AES since 2007-2008 with the release of Windows Vista and 
Server 2008. MIT Kerberos [MITKRB5] has fully supported AES enctypes 
since 2004 with the release of version 1.3.2, including the Kerberos 
mechanism for the Generic Security Service Application Program 
Interface (GSSAPI). Heimdal [HEIMDAL] has fully supported AES since 
2005 with the release of version 0.7. Though there may still be 
issues running ten-year-old unsupported software in mixed 
environments with new software, issues of that sort seem unlikely to 
be unique to Kerberos, and the administrators of such environments 
are expected to be capable of devising workarounds. 


6. Triple-DES Weakness 


The flaws in triple-DES as used for Kerberos are not quite as damning 
as those in RC4, but there is still ample justification for 
deprecating its use. As is the case for the RC4 enctypes, the 
string2key algorithm is weak. Additionally, the triple-DES 
encryption types were not implemented in all Kerberos 
implementations, and the 64-bit block size may be problematic in some 
environments. 
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Password-Based Keys 


The n-fold-based string2key function used by the des3-cbc-shal-kd 
encryption type is an ad hoc construction that should not be 
considered cryptographically sound. It is known to not provide 
effective mixing of the input bits and is computationally easy to 
evaluate. As such, it does not slow down brute-force attacks in the 
way that the computationally demanding PBKDF2 algorithm used by more 
modern encryption types does. The salt is used by des3-cbc-shal-kd’s 
string2key function, in contrast to RC4, but a brute-force dictionary 
attack on common passwords may still be feasible. 


Block Size 


Triple-DES is based on the single-DES primitive, simply using 
additional key material and nested encryption. Therefore, it 
inherits the 64-bit cipher block size from single-DES. As a result, 
an attacker who can collect approximately 2**32 blocks of ciphertext 
has a good chance of finding a cipher block collision (the "birthday 
attack"), which would potentially reveal a couple of blocks of 
plaintext. 


A cipher block collision would not necessarily cause the key itself 

to be leaked, so the plaintext revealed by such a collision would be 
limited. For some sites, that may be an acceptable risk, but it is 

still considered a weakness in the encryption type. 


Interoperability Concerns 


The triple-DES encryption types were implemented by MIT Kerberos 
early in its development (ca. 1999) and present in the 1.2 release, 
but they were superseded when encryption types 17 and 18 (AES) were 
implemented (by 2003); the AES enctypes were present in the 1.3 


release. The Heimdal Kerberos implementation also provided a version 
of triple-DES in 1999 (though the GSSAPI portions remained non- 
interoperable with MIT for some time after that), gaining support for 


AES in 2005 with its 0.7 release. Both Heimdal and MIT krb5 have 
supported the AES enctypes for some 12 years, and it is expected that 
deployments that support triple-DES but not AES are quite rare. 


The Kerberos implementation in Microsoft Windows has never 
implemented the triple-DES encryption type. Support for AES was 
introduced with Windows Vista and Windows Server 2008; older versions 
such as Windows XP and Windows Server 2003 only supported the RC4 and 
single-DES encryption types. 
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The triple-DES encryption type offers very slow encryption, 
especially compared to the performance of AES using the hardware 
acceleration available in modern CPUs. There are no areas where 
triple-DES offers advantages over other encryption types except in 
the rare case where AES is not available. 


7. Recommendations 


This document hereby removes the following RECOMMENDED types from 
[RFC4120]: 


Encryption: DES3-CBC-SHA1-KD 

Checksum: HMAC-SHA1—DES3-KD 
Kerberos implementations and deployments SHOULD NOT implement or 
deploy the following triple-DES encryption types: DES3-CBC-MD5(5), 


DES3-CBC-SHA1 (7), and DES3-CBC-SHA1-KD(16) (updates [RFC3961] and 
[RFC4120]). 


Kerberos implementations and deployments SHOULD NOT implement or 
deploy the RC4 encryption type RC4-HMAC (23). 


Kerberos implementations and deployments SHOULD NOT implement or 
deploy the following checksum types: RSA-MD5(7), RSA-MD5-DES3(9), 
HMAC-SHA1-DES3-KD (12), and HMAC-SHA1-DES3(13) (updates [RFC3961] and 
[RFC4120]). 


Kerberos GSS mechanism implementations and deployments SHOULD NOT 
implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC 
SHA1 DES3 KD(0400). (With all its content now deprecated, [RFC4757] 
has been made Historic by this document.) 


Kerberos GSS mechanism implementations and deployments SHOULD NOT 
implement or deploy the following SEAL_ALGs: RC4(1000) and 
DES3KD (0200) . 


Per this document, [RFC4757] has been reclassified as Historic. 
8. Security Considerations 
This document is entirely about security considerations, namely that 


the use of the triple-DES and RC4 Kerberos encryption types is not 
secure, and they should not be used. 
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IANA Considerations 


IANA has updated the "Kerberos Encryption Type Numbers" registry 
[IANA-KRB] to note that 1) encryption types 1, 2, 3, and 24 are 
deprecated, with [RFC6649] as the reference and that 2) encryption 
types 5, 7, 16, and 23 are deprecated, with this document as the 
reference. 


Similarly, IANA has updated the "Kerberos Checksum Type Numbers" 
registry [IANA-KRB] to note that 1) checksum type values 1, 2, 3, 4, 
5, 6, and 8 are deprecated, with [RFC6649] as the reference, and that 
2) checksum type values 7, 12, and 13 are deprecated, with this 
document as the reference. 
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